home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / UNSPLIT / text0551.txt < prev    next >
Encoding:
Text File  |  1997-02-06  |  2.2 KB  |  50 lines
  1. > > I have one (two) small question. How fast is it on the Afterburner040?
  2. > 
  3. > E1M1 (standard benchmark on startup):
  4. > 
  5. > 15 FPS -> 40Mhz 68040 / 50Mhz DSP / compat_level #2
  6. > 9 FPS -> 32Mhz 68040 / 32Mhz DSP / compat_level #99
  7. > 
  8. > I can only get away with compat_level #2 because my DSP is so speedy. This way,
  9. > the bus never catches up with it and the CPU barely needs to handshake at all.
  10.  
  11. But 15 fps isn't bad at all. :-) I think it's even a bit faster then before, right
  12. (I think it was about 11-12 fps on the AB)?
  13.  
  14. I guess you have plenty of time left on the 040 to put in some fancy audio effects.
  15. Multi channeld 16bit 3D sound. :-))
  16.  
  17. > > Will you do any modifications to speed it up further on the AB040?
  18. > 
  19. > Not much I can do that doesn't involve a big rewrite. :)
  20.  
  21. :-) What about your own free domain engine your were working on? :-))
  22. It would be funny to see such a engine on the AB040 running faster and better
  23. looking than Qukae. :-0
  24.  
  25. > > Johan talked about drawing the screen in Fast RAM and then copy it
  26. > > to 'video RAM' (ST-RAM). Or am I totatly wrong here? 
  27. > 
  28. > I tried that (used 'move16' to transfer 16-byte DPHRASE chunks on each instruction)
  29. > but it's just a fraction slower than normal. It is much faster than normal when
  30. > there are transparent textures on the screen though - makes a big difference there.
  31. > Might be a worthwhile option for nasty WADs. :)
  32.  
  33. Well, if it's faster with transperant textures I can't see why not the option should
  34. be there (if it doesn't mean to much work).
  35.  
  36. > The Falcon's 16-bit bus is so crap that the screencopy takes just as long as drawing
  37. > all of the pixels one by one in vertical columns. I imagine the fact that I pipelined
  38. > the drawing loops to death has contributed to this invariable screen access time. 
  39. > Badly pipelined code would have gained more from a FastRAM buffer because the loops
  40. > would 'choke' less on the delays caused by plotting to quick ram.
  41. > 
  42. > If the Falcon had a 32-bit bus then the difference would have been marked, but as
  43. > it stands there's not much hope for a fastram screenbuffer making a hell of an
  44. > improvement in most cases.
  45.  
  46. Well, if there will be a cheap graphics card then we can start talking... :-)))
  47.  
  48. //Magnus Kollberg
  49.  
  50.